Skip to main content

Networking based events/ Management protocol

High level: what are the key events with relation to the network

Note this should relate to DCON [https://specs.manysecured.net/DCon/DCon%20Protobuf](https://specs.manysecured.net/DCon/DCon Protobuf)

But this needs sanity checking

This is implicit on the current NIST flows

  • CMD: Onboard device

I don't think this is covered

  • CMD: Eject device

Common set of constraints

  • CMD: Subnet device

Cross subnet permissioning

  • CMD: Bridge device

Plus possibly do we need a CMD to fine grained control a specific device.

Specifically, this is looking at the protocol between the Access point (AP) and the continuous assurance service (CAS) - ie the continuous assurance protocol (CAP)

??? TODO: CAEP lookup ??

https://openid.net/wg/sharedsignals/

Questions that need asking

  1. Where does the CAS sit? I think we need to support local and cloud - but accept that cloud has issues if no networking connectivity

  2. Is the CAS->AP 1:1 or many to one? I think it has to be many to one relationship

  3. Can and API ever be drive by two CAS (many to one) in the other direction?

  4. How do we refer to a device? What identifier to do we use between CAS and AP? (IP and MAC address cleary no us) Public key/IdevID?

    1. Do we have mappings that work with legacy (vitual devid) ?

  6. Are there protocols we can reuse? SDWAN

  7. Is the CAS an extended registrar ?

CAP protocol​

The original notion was to use protobuf. This is what edgesec use.

However, if we are to support asynchronous many to one connections we need a different model

E.g CAS notifies 100 access points that a device is ok to be onboarded (eg. Office, hotel, manufacturing) . Or same device needs to ejected.

Current thinking: CAS issues “signed commands” (verifiable credentials) to APs on a pub sub hub model - where the CAS supports signed delivery.

Payload​

JSON or CBOR VC - where many claims can be attached - each of which is a command

Syntax for each command needs defining

Authentication is implicit in the payload signatory. AP must have CAS pub key installed as trusted rout

The advantage of this model is it can support air gapped management by usb key etc.

Protocol​

Using the VC model authentication is implicit in the signature, authorisation is implicit in the root of trust configured in the AP. That means the protocols can be much more flexible

Suggest the followinghe following options

  • HTTP(s): a single endpoint to retrieve commands. AP authenticates using its own key
  • TLS: common port similar model
  • USB/File: common folder to pick up commands.

Thoughts ??